分布式架构在云南红塔银行核心系统的实践

文 / 云南红塔银行信息科技部总工程师    谢红
云南红塔银行信息科技部运维中心经理    李建明

在金融服务互联网化、支付场景移动化以及金融服务普惠性发展的趋势下，银行核心系统需要面对海量交易、大促场景、7×24小时不间断服务的挑战，需要具备高性能、高可用、低成本、弹性伸缩的能力。针对以上技术要求，传统集中式架构已经难以应对，近年来银行业都在探索分布式架构，采用云计算、单元化、微服务、分布式数据库等技术来实现以上技术目标。分布式架构具备强大的扩展能力，在面对业务高速发展所带来的海量交易时有明显优势；但另一方面，分布式架构复杂度高，给应用开发和运维带来了一定挑战，尤其是底层数据分布对应用不透明、全局事务控制难度高、数据库实现双活难度大等问题，增加了系统建设的难度和成本。对于中小银行来说，受限于科技力量薄弱、项目预算有限等因素，这样一套从上到下完整的分布式架构虽然有一定优势，但驾驭起来是有难度的；并且从自身的业务特点考虑，也未必是性价比最高的选项。

云南红塔银行于2021年4月启动了新一代核心系统项目群建设，在综合考虑了当前业务的特点、行内的基础设施能力，以及未来发展规划的需要之后，决定在核心系统采用“云计算+微服务+分布式数据库”的技术底座。在这个技术底座的设计过程中，云南红塔银行充分参考了行业内的分布式架构实践，结合自身的特点和思考，在经典分布式架构基础上做了一些探索和改造，最终形成了自己的分布式核心系统建设实践。本文将详细介绍云南红塔银行分布式核心系统的技术架构、关键技术点的机制，以及性能优化的经验。

化繁为简的技术架构 

传统集中式架构由单体应用和集中式关系型数据库组成，是经典的“存算分离”架构，应用可以部署集群，集群中应用只在数据层面耦合，具有延迟低、运维简单的特点。但集中式架构的数据库实现双活难度大 、扩展性差，此外传统单体应用缺乏熔断限流、服务治理、运营管理等能力，因此难以应对海量交易和高可用性需求，而这些不足可通过微服务和分布式数据库解决。此外，借助云计算在IaaS和PaaS层提供的能力，可实现应用的弹性伸缩、自动发布等功能。

最终，借鉴集中式架构的优点，同时结合分布式架构的优势，云南红塔银行采用了一种更为精简的分布式架构，即“云化部署+全功能对等应用+原生分布式数据库”。

图1    核心系统架构

1.云平台

核心系统应用将涉及的微服务组件，包括API网关、服务调用框架、服务注册中心、配置中心、熔断限流、服务治理、链路追踪、监控告警、日志分析等都与云平台进行了适配改造，采用了云平台的标准组件，为日后技术架构的标准化奠定了基础。此外，也依托云平台实现了自动化和灰度发布、PaaS层弹性扩容等能力。该项目还通过对接IaaS和PaaS层建设了配套可观察系统，具备了一站式从业务视角发现问题，技术视角诊断问题的快速故障处理能力。

2.原生分布式数据库  

（1）部署模式

核心系统所使用的原生分布式数据库部署了两个集群，主集群为两地三中心五副本架构，单副本备集群异步同步主集群数据。其中“主城市”包含两个数据中心，每个数据中心两个副本；异地灾备数据中心部署主集群的一个副本和备集群。每个副本配置2台X86服务器，主集群中指定主副本散布到“主城市”两个数据中心的8台服务器，使得核心系统的数据表和表分区均匀分布在8个服务器节点。分布式数据库具备在线扩展能力，所有服务器节点是完全对等的，支持在线给副本添加服务器节点。在“主城市”一个数据中心发生整体故障时，分布式数据库采用Paxos协议，自动将主副本服务从故障数据中心的2个副本切换到同城数据中心的2个副本，在保证RPO=0的前提下，30秒内自动恢复数据库服务。

（2）业务访问方式

Proxy作为分布式数据库专用的反向代理软件，作用是将应用发起的数据访问请求转发到正确的数据库节点上。核心系统在每台数据库服务器都部署了Proxy，应用通过负载均衡访问同数据中心的Proxy，由Proxy将请求正确发送至主副本。由于主副本均匀分布在两个数据中心，所以每笔交易都可能跨同城数据中心访问，即同城两个数据中心作为整体为应用提供服务。当交易响应时间因跨数据中心网络延迟而不能满足业务需求时，可以将分布式数据库的主副本指定在一个数据中心，并将所有业务流量也路由到该数据中心部署的应用服务节点，避免了应用到数据库的跨数据中心访问；在数据库数据分布对应用透明的前提下，提升了业务体验。

3.应用系统

核心系统应用采用微服务架构，模块化开发，部署时可灵活组合发布微服务。云南红塔银行为了降低架构的复杂性、提升资源利用率、降低系统响应时间，最终只部署了联机和批量两个微服务。核心系统应用具备全局缓存以及交易级缓存，全局缓存加载了系统字典表及配置表数据；在同一次交易中，不同模块之间有重复查询数据库的情况下，采用交易级缓存后，将大幅减少访问数据库的次数。

全功能对称双活

在数据容灾方面，核心系统分布式数据库采用了主集群+异步备份集群的部署架构，数据层面可以做到同城容灾RPO=0、RTO<30秒，达到灾难恢复能力6级的水平。在应用容灾方面，由于应用采用了全功能对等部署，业务请求可以发送到同城任意一个数据中心部署的核心应用，每个应用只访问本数据中心的Proxy，不同数据库服务器之间的交互由分布式数据库内部机制实现，所以同城两个数据中心都可支撑全业务的访问。利用这种架构，最终在应用和业务层面都做到了同城容灾RPO=0、RT0<30秒，达到灾难恢复能力6级的水平。

分布式事务控制

对于分布式系统，在应用和数据进行分布式拆分后，存在大量分布式服务和分片数据访问，一次交易需要调用多个服务和访问多个数据库节点才能完成，对保证数据一致性和系统性能提出巨大挑战。为了有效应对分布式调用带来的一致性及响应延迟问题，云南红塔银行在核心系统应用层面只保留了联机和批量两类微服务，而且服务之间的调用不涉及分布式事务。跨机器的数据访问由分布式数据库统一处理，对上层应用完全透明。

1.分布式事务机制

原生分布式数据库的分布式事务采用两阶段提交（2PC），但不同于传统2PC的经典架构。首先原生分布式数据库的分布式事务协调者为无状态设计，不再单独维护协调者的持久化状态，持久化状态由各参与者保证。其次分布式事务协调者在收到所有参与者PREPARE阶段成功的应答后，即可向用户返回事务成功。改进后的分布式事务机制避免了协调者写日志，简化了传统2PC在COMMIT成功前的处理流程，降低了传统2PC远程调用和日志持久化操作所带来的开销，提高了2PC的性能，可满足生产使用时的性能需求。

2.分布式事务优化

对于分布式系统来说，如何减少远程分布式调用是降低业务响应时间的关键。而对于云南红塔银行核心系统架构来说，远程分布式的调用主要是由分布式数据库执行，因此优化的重点就是减少数据库内部的远程调用次数。

根据原生分布式数据库的事务处理机制，在事务的开始阶段会分配一个协调者，由协调者根据事务中每条SQL的数据主副本所在位置，将SQL转发给对应的服务器来处理。如果事务中SQL数量过多，并且不同SQL处理的数据分散在集群中不同的服务器上，就会导致数据库内部的远程调用次数过多，交易响应时间变长。为了减少远程调用的次数，分布式数据库内采用了多种优化方式：其中“表组”功能用于将有关联性的表通过关联键作为分区键，使得不同表的关联分区的主副本配置在同一个物理节点上，增加关联数据在物理位置上的亲和性，降低跨机访问的概率；此外，通过数据库内部的参数调整，在事务中SQL数量很多的情况下，可以让事务协调者的选取更加智能，直接减少远程访问SQL的次数。借助分布式数据库的这些功能，在没有改变交易数据处理逻辑的前提下，交易中远程SQL的数量有了明显减少，降低了交易的响应时间。

性能优化经验

云南红塔银行在性能测试时，应用采用20台X86计算节点（共800物理核）、分布式数据库采用12台X86服务器（共768物理核）、账户数和客户数均为7000万的情况下，混合场景实测的TPS达到8000、平均响应时间小于300毫秒。

1.优化策略 

（1）全链路分析

鉴于分布式系统链路长、拓扑结构复杂，同时核心系统应用的高度参数化，一笔账务交易需要访问200～300余次数据库的特点，我们通过“抽丝剥茧”的方式进行了全链路分析。借助链路跟踪工具、JVM分析工具、以及操作系统层面TcpDump、Perf等工具构建出了整个交易的全链路耗时图谱，细到每一个SQL、函数、交换机等。通过重点优化每一个高频交易，力争使应用、数据库、服务器各尽其能，发挥出所有硬件及软件的优势，性能做到极致。

（2）压满数据库CPU

原生分布式数据库采用了LSM-Tree结构的存储引擎，较传统集中式数据库而言，IO不容易成为瓶颈，因此我们制定了压满数据库CPU的策略。我们采用网联记账交易来实现将后端数据库CPU压满的目标，通过不断增加应用实例节点，最终将数据库CPU压到97%以上，交易TPS突破2600，同时响应时间保持在500毫秒以内。在测试过程中，我们发现针对该交易应用所在虚拟机在8C8G的配置下性能最优；发现并解决了数据库服务器双网卡绑定策略错误的问题，以及网卡通道的CPU亲和性设置不合理导致数据库服务器系统软中断过高等问题，确保交易压力能顺利传导至分布式数据库。

2.关键优化点

（1）优化云环境网络路径  

考虑到应用与数据库高频交互的特点，应用部署到云内虚拟机上，而数据库是云内物理机部署，如何将underlay网络上的数据库和overlay网络上的应用之间的网络延时降到最低，是提高系统整体性能的一个关键因素。经过理论推导、安全论证、测试对比等多个步骤，最终决定将数据库部署在云的客户网络互联接入区，使网络延时降低到0.18毫秒左右。

（2）数据库层面的优化

分布式数据库是索引组织表（IOT），建立和业务逻辑相关的主键可以减少数据访问的回表操作；

对于大数据量的表，建立分区表有利于降低SQL的响应时间，并将吞吐量分散至多台物理服务器上，当然也需要权衡分区表情况下全局索引和本地索引的使用。

总结及展望

1.“云化部署+全功能对等应用+原生分布式数据库”可作为中小银行分布式架构实践的一种选择

云南红塔银行核心应用只拆分了两种微服务，微服务之间调用不涉及事务，对于数据拆分引起的事务，由数据库进行控制。该架构在硬件投入很小的情况下得到良好的性能，也说明由数据引起的分布式调用由数据库控制是更好的实践；这种方式也让应用不需要为了分库分表而进行分布式事务控制，降低了应用的复杂度；一个统一的数据库集群对于运维的管理难度更低。

2.分布式数据库可改进点

本次实践中也发现，虽然应用可以通过调整SQL顺序来减少远程SQL的次数，但对应用开发有一定的侵入。如果原生分布式数据库在这方面处理得更加智能，进一步增加事务内本地SQL执行的数量，减少远程SQL的调用次数，将会带来更好的性能，并且对应用会更加透明。

此外，在当前的架构下，分布式数据库服务节点之间的远程调用，以及Proxy访问数据库服务节点，二者都采用了相同的服务端口，因此无法在网络层面区分二者的流量。如果可以将分布式数据库服务节点之间的访问端口独立出来，就可以进一步优化数据库服务节点之间的跨数据中心通信线路，降低网络延时。

因此，原生分布式数据库在保证高可用、动态负载均衡、灵活水平扩展等优势的前提下，可以进一步了解传统银行核心系统的业务特征，以及对数据库的使用模式，并在产品层面作出相应的优化，这样就能更好地满足银行传统业务的需求，具有更广阔的使用场景。

推荐阅读

（点击图片查看精彩内容）

精彩内容回顾

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪